Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Some of the most malicious software, also known as malware, capable of crippling a computing device or even an entire corporate network, are being distributed worldwide via electronic mail (“email”) and email attachments. As individuals and businesses become increasingly dependent on email communications, the likelihood of such programs setting off disruptive consequences has also increased considerably. Further complicating the matter is that some email attachments are compressed to conserve communication bandwidth. Finding malware in such compressed attachments generally involves decompressing the entire compressed attachments before scanning the uncompressed version of the attachments.
One approach employed by existing anti-virus solutions is to filter out an attachment file based on its extension. Thus, if the attachment file has a known compression extension, such as zip, then the attachment file is blocked from reaching users of such solutions. However, since this approach does not inspect the content of the attachment file, a legitimate and a malware-free attachment file may be erroneously filtered out.
Another approach employed by the anti-virus solutions is to recommend or even require a user of the solutions to decompress and scan the compressed attachment file for malware prior to permitting the user to access the file. After an affirmative act by the user, such as manually electing to start the decompressing and scanning process, the entire attachment file is temporarily stored either on the user's computing device or on the mail server on the network for processing. Unlike the first approach discussed above, this approach inspects the content of the attachment file. However, the inspection takes place only after the entire file is stored and decompressed. By its nature, a compressed file tends to contain a large amount of information when it is in its uncompressed state. Since the entire uncompressed file is stored and inspected, this approach consumes significant processing and memory resources. When faced with multiple attachments from different email sessions concurrently, the resource requirements of this approach renders the implementation of the approach impractical and prohibitively expensive.
As the foregoing illustrates, what is needed is a way to efficiently and yet thoroughly inspect the content of these compressed attachment files in email communications.